🔁 Pushing funds to a card

Two messages, one pair

A push-to-card payout is a transaction in which an originator sends funds to a cardholder, using the card number as the destination address. It consists of two separate messages. The first debits the sender's card; the second credits the recipient's. Visa calls the first an Account Funding Transaction (AFT) and the second an Original Credit Transaction (OCT). Mastercard handles both in its MoneySend program, marketed under the Mastercard Move umbrella brand, which succeeded Mastercard Send. Both messages run on the purchase authorization infrastructure, in the same formats and between the same parties: acquirer, network, and issuer. Behind that technical sameness are two transactions with opposite economics, each subject to its own authentication, recourse, and compensation rules.

The AFT is a debit message that uses the format and processing of a purchase authorization, except that what is being sold is money rather than goods. To the network, the originator is a registered merchant. It debits the sender's card for an amount it collects through its acquirer and holds until the credit goes out. The sender's issuer approves or declines under its own rules. In the European Economic Area, strong customer authentication applies as it would to any payer-initiated payment. The cardholder keeps the recourse that Article 73 of PSD2 provides for unauthorized transactions. Their provider must refund them by the end of the business day after the report at the latest, unless it suspects fraud, which it has to substantiate.

The OCT is a credit message sent to a card number, with no prior purchase behind it. The originator sends it, the receiving issuer accepts it, and the cardholder receives funds without having requested anything as far as the message is concerned. The recipient never authenticates, since they are not a party to the transaction. Their card number serves only as the destination address. All the network knows about the recipient is that number and a name supplied by the sender, and no rule requires that name to be matched against the actual cardholder.

What's allowed, and who is accountable for what

The use case is the value, carried in the payout message itself, that declares the economic purpose of the transaction. Visa carries it in a field called the Business Application Identifier, whose values are listed in the Visa Direct product requirements. Mastercard carries an equivalent identifier in MoneySend, with values set out in its processing rules. The labels differ from one network to the other, but the families of use cases largely overlap. They include person-to-person transfers, transfers between two cards held by the same person, and business-to-consumer disbursements. They also include government disbursements, merchant or seller settlements, loan repayments, and gambling payouts.

This declaration isn't there for statistics. It determines the fee schedule, the countries where the transaction is accepted, the card products that can receive it, and the checks required of the originator. The same amount sent to the same PAN goes through or fails depending on the declared value. Declaring an inaccurate use case to get around a decline violates network rules. Networks catch it after the fact through traffic pattern analysis, long after the configuration was set up and forgotten.

Each network sets its own list of prohibited sectors. The lists overlap without being identical, and they change faster than the integrations that turn them into rejection rules get updated. They cover activity that is illegal in the sending or receiving country, adult content depending on the market, unlicensed gambling, sales of medicines outside regulated channels, and weapons and ammunition. A second category covers use cases allowed with prior approval, including licensed gambling and crypto-asset purchases. Acceptance of the first messages does not mean that approval has been granted, and a noncompliant program comes to light at the network's first review.

The originator carries three obligations that the message doesn't show, and no network fulfills them on its behalf. The first is identifying the sender to the standard its own license requires, which depends on the country where it operates, not the country of the card. The second is screening both parties against sanctions lists. On the recipient side, the originator has only a number and a name that no one is required to verify. Screening therefore falls back on the data the sender provides and on the receiving issuer's country. The third is monitoring for repetition: a single payout gives nothing to go on, while a series sent to the same PAN from different senders is a red flag.

Limits, availability times, eligibility, and failures

Eligibility is a given card's ability to receive a push credit, as reported by the network in response to a query on the card number. The query comes before the send. The answer is more than a yes or no. It gives the product type, the issuer's country, the billing currency, and whether the card participates in the fast-funds program. Depending on the network, it also lists the use cases open for that card range. At Visa, the push and pull resources are called pushfundstransactions and pullfundstransactions, and they are normally preceded by an attributes inquiry.

The timing promised to the recipient depends on the eligibility response for their card, not on a rule that applies across the rail. Visa publicly advertises funds availability in 30 minutes or less for cards eligible for its Fast Funds program. Its own documentation adds a written caveat: actual availability depends on the receiving institution. Showing that timing to every user without checking card by card therefore promises a performance the service doesn't control. A decline leaves the service free to offer another channel without having broken any promise. An approval followed by a multi-day wait, on the other hand, leaves the user with a written record of a promise that wasn't kept.

Three limits stack up on the same transaction, and the originator knows only two of them. The network sets a maximum amount per transaction, which varies by region and use case. The originator then sets its own limits, usually lower, and adds velocity rules per sender, per recipient, and per time period. The third limit belongs to the receiving issuer, which caps what its card can receive without publishing the figure. That unpublished limit explains some of the declines that message analysis can't attribute to any cause, and only the recipient can get it lifted, by contacting their issuer.

• Non-participating issuer. The card range is not open to push payments; no message configuration will change that answer.
• Excluded card product. Commercial cards, anonymous prepaid cards, and some credit cards are excluded depending on the declared use case.
• Closed corridor. The sending country–receiving country pair isn't open for this use case, even though it is open for another.
• Unsupported currency. The issuer doesn't accept the sending currency, or accepts it and applies its own conversion to the cardholder.
• Account status. Card expired, blocked, or reported lost or stolen, or account closed; the decline is final, and the number must not be kept for another attempt.
• Receiving limit reached. An issuer-specific, unpublished, often monthly limit that kicks in partway through a series of sends that had been accepted until then.

A push credit to a credit card doesn't work the way it does on a debit card. It reduces the balance owed on the card account and doesn't make any cash available to the cardholder. A recipient whose card balance is zero ends up with a credit balance. Some issuers refuse to create one. Others refund it by bank transfer, which takes so long that it defeats the purpose. A payout flow that accepts any card number without distinguishing debit, prepaid, and credit inevitably generates complaints that support teams can't resolve, because the cause lies in the recipient's card product.

The economics: two interchange fees, one reversal, and a comparison that depends on the country

The full cost of a card-to-card payout has seven components, split between the transaction's two legs and the intermediaries that process them. A provider's quote almost never itemizes all of them. The funding leg carries the interchange owed to the sender's issuer and network fees. The push leg carries the fee paid to the recipient's issuer and a second set of network fees. On top of that come the fee charged by the originator or its platform, the cross-border fee when the two countries differ, and the FX margin when the two currencies differ. Comparing two offers requires rebuilding all seven lines for each one; otherwise, you are comparing price presentations, not costs.

The regulatory status of this fee is less settled than that of purchase interchange. Regulation (EU) 2015/751, the Interchange Fee Regulation (IFR), caps interchange on card-based payment transactions. Its Articles 3 and 4 set caps of 0.2% for consumer debit and 0.3% for consumer credit. Whether it applies to push transfers has been debated, because the transaction doesn't pay for any goods or services. For the European Economic Area, the networks publish transfer fee schedules separate from their purchase categories. A cost model built on the IFR caps therefore uses the wrong benchmark. The right one is the transfer fee schedule for the relevant region, which the acquirer should confirm in writing before any pricing commitment.

Currency conversion can be set up in two ways, with opposite effects on the amount the recipient gets. The originator can push in the billing currency of the destination card. The recipient then gets exactly the amount quoted, since the conversion happened on the originator's side. Or it can push in another currency and let the issuer convert. The amount received then depends on that issuer's rate, and sometimes on a foreign transaction fee applied to the credit. The second setup makes it impossible to guarantee the amount received. Some services show an estimate anyway, which the recipient's statement then contradicts.

In the euro area, the cost comparison between push-to-card and the bank rail favors the bank rail. Regulation (EU) 2024/886 has required providers to receive instant credit transfers in euros since January 9, 2025, and to send them since October 9, 2025. It bars charging more for them than for a standard credit transfer. A domestic euro disbursement therefore costs the price of a bank transfer, while the same disbursement pushed to a card carries two issuer fees and two sets of network fees. Those four items make up the difference, which the capped price of an instant transfer doesn't have to cover, and they weigh heavily against the card rail.

The picture flips when the bank rail offers no usable address, either because the recipient has no bank identifier or because there's no route to reach them. A recipient with a prepaid card and no addressable bank account has no IBAN to give. A corridor with no direct correspondent bank forces a bank transfer through a chain of intermediaries, and neither the timing nor the final cost is known at send time. In many countries, domestic instant payment systems accept only locally established participants, which rules out a foreign originator. In all three cases, the card number is the only routable address the recipient has, and it can be shared over any ordinary channel, such as a text message.

Push-to-card sits in the middle of the price range tracked by the World Bank. The card rail costs more than the cheapest digital offers measured, because it pays two institutions along the way. But it doesn't reach the top of the range, which the World Bank places on the bank channel side. Its advantage therefore lies elsewhere than price: in reaching the recipient, and in speed when the issuer participates in the fast-funds program. A card number can be entered without a bank code, without a branch code, and without depending on any national format.

Operations: declines, reconciliation, sanctions, and AML

A decline is a response by which the issuer, the network, or the originator itself rejects the transaction before funds are made available. It should be read differently from a purchase decline. A purchase decline often reflects a temporary condition, such as insufficient funds or a fraud suspicion cleared by a phone call. A push credit decline reflects a structural condition whenever it stems from the issuer, the card product, or the corridor. That condition will be the same on the 10th attempt, and retrying unchanged makes things worse instead of fixing them. The right approach is to classify the decline, turn off automatic retries for the permanent categories, and switch to another instrument rather than keep trying.

Reconciliation for a payout service is built around a constraint the bank rail doesn't have. Two messages produce two clearing records, and nothing guarantees they land on the same day or carry the same amount. Fees get deducted along the way, conversion may apply on one side only, and a late reversal on the funding leg arrives after the credit. Matching must therefore rely on an identifier the originator itself puts on the pair. That identifier travels in both messages, is kept in the logs, and shows up in the network's clearing files. Amount-based matching fails as soon as any of these discrepancies occurs.

The anti-money laundering regime for push-to-card payouts depends on what the card is used for, not on the instrument itself. Regulation (EU) 2023/1113, in effect since December 30, 2024, requires information on the payer and the payee to accompany transfers of funds. Card transactions are excluded when the card is used solely to pay for goods or services. The exclusion no longer applies when the card is used as a payment system for a person-to-person transfer. A payout from one individual to another is therefore in scope, with the collection, transmission, and retention obligations that come with it. FATF Recommendation 16 draws the same line, and it applies beyond the EU in the jurisdictions that have implemented it.

Operational monitoring is therefore built around the signals the message does reveal, and there are few of them. The first is the destination card number: a single card funded by unrelated senders is the clearest sign of fraudulent collection. The second is the ratio of distinct senders to destination cards. The third is how soon a new sender account makes its first payment to a distant country. These signals also show up on other instruments, but they matter more on push payments, where no recall mechanism allows correction after the fact.

• Check the card number's eligibility before promising a timeline, and drop the speed promise when the issuer doesn't participate in the program.
• Push only after funding is confirmed, never the other way around, however much pressure the user journey creates.
• Put a unique identifier on the pair and match on it, because amounts diverge as soon as a fee or conversion comes in between.
• Write the refund path for the funding-approved, credit-declined case before go-live, with its contractual deadline and customer message.
• Configure the two legs separately, because a rule that works for funding is worthless for the credit, whether for merchant category codes or card products.
• Budget on the network's transfer fee schedule, region by region, not on the interchange caps that apply to purchases.
• Treat fraud on the funding leg as a total loss, since a credit already pushed can't be recalled and no dispute right reaches it.
• Document the payer and payee data transmitted, under Regulation (EU) 2023/1113 in the EU and FATF Recommendation 16 elsewhere.