Visa Direct and Mastercard Send OCT: Addressing KYC and Fraud

Push-to-card payouts have become the default for gig payouts, remittances, insurance disbursements, and marketplace payments — because they land in minutes rather than days. But every Original Credit Transaction (OCT) sent through Visa Direct or Mastercard Send carries a fixed set of mandatory checks the networks require before the transaction can be sent. Skip them and the money either doesn’t arrive, arrives on a card that doesn’t accept OCTs, or lands on the wrong person’s card entirely. This guide covers the three checks that must run before an OCT: card eligibility, Account Name Inquiry (ANI), and KYC — and why Inyo’s APIs treat them as a single pre-flight rather than three separate integrations.

The Three Mandatory Checks Before Every OCT

A push-to-card payout — whether over Visa Direct as an Original Credit Transaction (OCT) or over Mastercard Send — is a one-way, real-time movement of funds to a cardholder’s card. Because there’s no cardholder authentication step at the point of sending, and because push payments settle nearly instantly, the network rules put the verification burden on the sender before the transaction is initiated.

In practice this means three checks have to run before every OCT:

1. Card eligibility. Is this specific card actually able to receive an OCT? Not every Visa or Mastercard card is enrolled in Fast Funds / real-time push programs. Some are blocked from disbursements entirely (prepaid restrictions, sanctioned recipients, closed accounts). Sending an OCT to an ineligible card either gets rejected outright, or worse, gets accepted and then lost in reversal purgatory.
2. Account Name Inquiry (ANI). Does the name you have on file actually match the name the issuer has for this card? This is the anti-impersonation check — making sure the person you’re paying is who they say they are, not a fraudster who provided a stolen or borrowed card number.
3. KYC. Do you know the recipient (and, for many corridors, the sender) at the regulatory identity level — verified identity documents, sanctions screening, PEP checks, and where required, source-of-funds verification? This is the compliance floor beneath the fraud checks above.

None of the three is optional. Skipping card eligibility gets you failed transactions and support tickets. Skipping ANI gets you fraud losses and reputational damage. Skipping KYC gets you AML fines and, in some markets, a shutdown from your acquirer. The question isn’t whether to do them — it’s how to run all three inline before an OCT without turning your integration into a three-vendor spaghetti.

Check 1: Card Eligibility — Is the Destination Card OCT-Enabled?

Not every card can receive an OCT. Card eligibility depends on three orthogonal factors, and all three must pass:

• Issuer participation in the push program. The issuing bank must be enrolled in Visa’s Fast Funds program (for Visa Direct) or in Mastercard Send (for Mastercard). Enrollment varies by market — large US issuers are almost universally enrolled; smaller regional issuers, credit unions, and issuers in certain emerging markets often are not.
• Card product support. Some card products don’t support push at all — certain corporate cards, some prepaid programs, and some virtual-card issuances. The BIN identifies the card product; the eligibility check reads the BIN’s support flags.
• Per-card status. Even on an enrolled issuer with a supported product, an individual card can be blocked from disbursements — account closure, fraud flag, sanctioned recipient, cardholder-elected block. This is the “disbursement blocked” flag returned by the network’s card-check API.

The right check to run is a Visa Card Enquiry or Mastercard equivalent BIN/card check that returns, at minimum:

• fastFunds — whether the card is enrolled in the real-time push program (30-minute delivery guarantee)
• disbursementsBlocked — whether the card is blocked from receiving any OCTs at all
• gamblingDisbursementBlocked / mtBlocked — category-specific blocks (gambling payouts, money transfer / remittance payouts) that some issuers apply
• schemeSupportedByFfs — whether the card’s scheme (Visa, Mastercard, or a co-badged variant) supports Fast Funds at the network level
• issuerCountryCode and cardType — needed for corridor routing and, in some cases, for compliance screening

Running the eligibility check before initiating the OCT lets you either route the payment down the OCT rail (when the card supports it), fall back to a slower ACH/bank rail (when it doesn’t), or reject the transaction with a specific reason before any money moves. All three outcomes are correct — guessing is not.

Check 2: Account Name Inquiry (ANI) — Is the Cardholder Who You Think They Are?

Card eligibility tells you the card can receive money. It doesn’t tell you the name on the card matches the person you’re paying. That’s where Account Name Inquiry (ANI) comes in — a Visa-provided API that lets you submit a name and card number and receive a match decision from the issuer.

The ANI request carries the destination card’s PAN plus the recipient’s first, middle, and last name. The issuer compares those name fields against what they have on file for that card and returns:

• Match — the name on file matches the name submitted, with high confidence.
• Partial Match — one or more name fields match (e.g. last name matches, first name doesn’t). Useful for surnames after marriage, hyphenated names, transliteration variance.
• No Match — the name on file doesn’t match. Strong signal not to send.
• Name match not performed — the issuer doesn’t participate in ANI, or the card is a corporate/anonymous product where name matching isn’t meaningful.

The response comes back per field (first name, middle name, last name) plus an overall decision. Match codes are standardized: 01 for Match, 50 for Partial Match, and higher codes for No Match variants. The per-field granularity matters because it lets you make smart decisions: last-name match with first-name mismatch is usually a legitimate name variation (marriage, cultural naming order), while first-name match with last-name mismatch is a much stronger fraud signal.

Mastercard offers an equivalent service through its money-movement platform, with similar match/partial-match/no-match semantics. In both cases, the recommendation from the networks is the same: run ANI before every high-value OCT, and treat No Match as a block (or an escalation to manual review), not a warning.

A subtle point: ANI is not a fraud tool in isolation — it’s a data-verification tool. It catches typos, stolen card numbers being paired with fake names, and mule accounts where the fraudster provided a real card belonging to someone else. It does not catch scenarios where the cardholder is the fraudster (first-party fraud). That’s what KYC is for.

Check 3: KYC — Do You Know the Recipient at the Compliance Level?

Card eligibility tells you the rail works. ANI tells you the name on the card is the right person. KYC tells you the right person is someone you’re actually allowed to pay — and that your compliance obligations to your regulator, your acquirer, and the card networks are satisfied.

For OCT-based payouts, the KYC surface depends on your role in the transaction:

• Sender KYC. If you’re a money transfer operator, marketplace, or platform initiating OCTs on behalf of a paying customer, you need identity verification on the sender — documents, biometric or database checks, and sanctions/PEP screening. This is standard AML/CFT and largely doesn’t change because of the OCT rail.
• Recipient KYC. For push-to-card, the recipient may be a repeat participant on your platform (a gig worker, a policy holder, a marketplace seller) — in which case you’ve already KYC’d them at onboarding — or a one-time recipient (a remittance beneficiary, an insurance claimant). The compliance floor for one-time recipients is usually lighter but not zero: at minimum, sanctions and PEP screening on the name and destination country.
• Corridor-specific rules. Some corridors carry additional obligations — enhanced due diligence for high-risk jurisdictions, source-of-funds documentation above certain amounts, purpose-of-payment codes for specific categories (crypto cash-out, gambling, cross-border remittance). Visa’s OCT compliance framework encodes many of these as required transaction fields, not as loose guidance.

The right KYC posture ties into the OCT itself: the identity data you collected at onboarding (or at one-time payout collection) feeds directly into the OCT’s sender/recipient fields, into the ANI request, and into the sanctions screening that runs alongside the transaction. Treating KYC as a separate world — done at signup, forgotten by the time the payout runs — is how compliance failures happen.

Related reading: our KYB onboarding guide covers the business-side equivalent for payment platforms onboarding merchants and sub-merchants.

What Visa and Mastercard Actually Require

The rules aren’t a single document. What Visa and Mastercard require for OCTs is a stack of overlapping obligations:

• Visa’s Fast Funds / Visa Direct program rules. Issuers and acquirers registered for Visa Direct must comply with the OCT operating rules — including transaction categorization (business application identifier, source of funds indicator), sender data requirements, and sanctions screening obligations. See our Visa Direct guide for the mechanics.
• Mastercard Send program rules. Mastercard’s equivalent framework carries analogous obligations — program registration, use-case categorization, sender/recipient data requirements, and compliance screening.
• Cross-border compliance frameworks. For international OCTs, both networks apply cross-border rules that require identity data, purpose-of-payment codes, and (in some corridors) currency-conversion transparency to the recipient.
• Local AML/CFT regulation. Whatever your regulator requires — FinCEN in the US, FCA in the UK, MAS in Singapore — sits on top of the network rules. Card networks won’t enforce your local regulation, but your acquirer will require compliance with it.

These aren’t “nice to haves.” Non-compliance surfaces as: card network fines against your acquirer (which passes them to you), acquirer termination, chargeback disputes with a lower probability of winning, and in some markets, direct regulatory action. The mandatory pre-flight checks — eligibility, ANI, KYC — exist to make those consequences avoidable.

The Fraud Patterns These Checks Defend Against

Each check maps to a specific fraud pattern the industry has been fighting for years:

• Stolen card + fake name (defeated by ANI). A fraudster obtains a stolen card number, signs up on a platform under a false name, and requests a payout. Card eligibility passes (the card is real). But ANI catches the name mismatch: the issuer’s records show a different cardholder than the platform’s signup data.
• Money mule accounts (defeated by KYC + ANI + transaction monitoring). A fraudster recruits a legitimate person as a mule — the mule opens a real account under their real name, ANI matches, but the account exists solely to receive fraud proceeds and forward them. KYC alone doesn’t stop this; you need behavioral monitoring on top.
• Push to ineligible card (defeated by eligibility check). Not a fraud pattern per se, but a common cause of “lost” transactions — the merchant sends an OCT to a card that doesn’t accept OCTs. Some acquirers accept the transaction, take the fee, then can’t deliver it and the money enters reversal purgatory. Eligibility check up front avoids the whole scenario.
• Sanctions evasion (defeated by KYC + sanctions screening). A recipient on an OFAC or equivalent sanctions list. The card eligibility check won’t catch this; ANI won’t catch this; only a KYC pipeline with real sanctions screening will.
• First-party fraud / friendly fraud (partially defeated by ANI + strong KYC). The cardholder is the fraudster — they use their own card, provide their own name, and later dispute the OCT’s originating charge. ANI doesn’t help here; strong sender KYC and behavioral monitoring do.

The pattern to notice: no single check catches all fraud. Eligibility catches operational failures. ANI catches name-mismatch fraud. KYC catches identity and sanctions issues. Behavioral monitoring catches mules and first-party fraud. A serious anti-fraud posture runs all of them, and treats each as a distinct control rather than a single “fraud check.”

Implementing the Pre-Flight Without Three Separate Integrations

The common failure mode when implementing OCT pre-flight is stitching three separate vendors together: one for KYC (Onfido / Persona / Trulioo), one for card checks (an acquirer’s BIN lookup API), one for ANI (via a scheme-connected provider). This works, but it means three integrations, three billing relationships, three sets of latency budgets, and three places where a decision can silently disagree.

A cleaner pattern is a single OCT API that runs all three checks inline before the transaction is sent, and returns a unified decision:

1. Merchant submits the OCT request with recipient identity data (name, DOB, address, sanctions-screening inputs) alongside the card details.
2. The API runs card eligibility — BIN check + card check — and either aborts with a clear reason or proceeds.
3. If the request includes name data, ANI runs against the destination card. Match / Partial Match feeds a risk score; No Match aborts the transaction with a specific error the merchant can surface to the customer.
4. KYC screening (sanctions, PEP, adverse media) runs on the recipient identity data. Any hit blocks the transaction and triggers the compliance workflow.
5. All checks pass → the OCT is sent through Visa Direct or Mastercard Send, tagged with the compliance evidence required by the scheme rules.

The point isn’t that this is easier to code — it’s that the checks stay in sync. When card eligibility, ANI, and KYC are three separate systems, it’s possible for one to update its rules without the others knowing, leaving gaps a fraudster can exploit. When they’re one integrated pre-flight, the rule updates land together.

The Inyo Approach: One OCT API, Three Checks Underneath

Inyo’s OCT / Global Payouts API runs card eligibility, ANI, and KYC as a single pre-flight before every push-to-card transaction. The merchant sends one payout request with recipient identity data; the platform runs the three checks inline; the OCT is either sent to the network (with compliance evidence attached) or rejected with a specific, actionable error.

What this collapses in practice:

• Card eligibility — run inline via Visa Card Enquiry and Mastercard’s equivalent. Fast Funds enrollment, disbursement blocks, category-specific blocks, scheme support — all resolved before the OCT is initiated.
• ANI / Name Match — Visa ANI and Mastercard Name Match run automatically when name data is provided. Match / Partial Match / No Match feeds the risk decision; the merchant sees a single result, not two provider responses to reconcile.
• KYC screening — sanctions, PEP, and adverse-media screening run against the recipient identity data on every OCT. Hits block the transaction and route to a compliance workflow; clears proceed with the compliance evidence stored for audit.
• Compliance data on the wire — the OCT is sent to Visa Direct or Mastercard Send with all scheme-required fields (business application identifier, source-of-funds indicator, purpose-of-payment code, sender/recipient identity fields) populated correctly. No missing-mandatory-field errors from the network.

The commercial effect: OCT throughput goes up (fewer failed transactions), fraud losses go down (all three checks running on every payout), and compliance posture improves (the evidence trail is built into the transaction, not stitched together after the fact).

Frequently Asked Questions

Is ANI mandatory for every OCT?

The card networks don’t require ANI on every single OCT — but they strongly recommend it for high-value payouts, first-time recipients, and cross-border transactions. In many corridors, running ANI is also a component of the compliance evidence acquirers require to keep an OCT program in good standing. In practice, running ANI on every OCT above a low threshold is the standard operating posture.

What’s the difference between a card eligibility check and ANI?

Card eligibility asks “can this card receive an OCT?” It returns yes/no plus category flags (Fast Funds, disbursements blocked, etc.). ANI asks “does the name I have match the name on this card?” It returns a match decision per name field. They’re orthogonal checks — a card can be eligible but the name can be wrong (stolen card fraud), or the name can match but the card can be blocked from disbursements (issuer-specific restriction). Both must pass.

How does ANI work for names with cultural variance — hyphenated names, non-Latin scripts, married names?

This is where the Match / Partial Match distinction matters. A hyphenated last name that the issuer stores unhyphenated will return Partial Match, not No Match. A name in a different Latin transliteration (e.g. “Jose” vs “José”) will typically return Partial Match. A married name change where the issuer has the maiden name will return Partial Match on last name and Match on first name. The right integration pattern is to treat Partial Match as a risk signal to score, not an automatic block — and only block on No Match.

What happens if I send an OCT to a card that’s not eligible?

Best case: the acquirer or network rejects the transaction up front and you can retry via a different rail. Worst case: the transaction is accepted, funds are debited from your account, and the OCT gets stuck in reversal — typically resolved within a few business days but sometimes weeks. In either case, you’ve incurred fees for a transaction that didn’t deliver. Running the eligibility check pre-flight prevents both outcomes.

Do I need to run KYC on every OCT, or just at onboarding?

Full-document KYC is typically an onboarding event — you verify identity once when the recipient is added to your platform. But sanctions and PEP screening should run at both onboarding and at transaction time, because sanctions lists change constantly and a previously-clean recipient can appear on a list months later. Any serious compliance posture runs sanctions screening on every OCT, not just at signup.

Does Mastercard have an equivalent to Visa’s ANI?

Yes. Mastercard offers name-matching services through its money-movement platform, with similar match/partial/no-match semantics. The integration surface is different, but the operational role — verifying that the name you have matches the name the issuer has — is the same. A properly designed payout platform runs the appropriate service based on the destination card’s scheme.

Can I skip these checks for repeat recipients I’ve already verified?

Card eligibility should still run every time — card status changes (blocks, closures, new fraud flags) don’t propagate automatically. Sanctions screening should also run every time, since sanctions lists update continuously. Full-document KYC and ANI can typically be cached after initial verification, but the caching window depends on your regulatory regime — some markets require periodic re-verification (annually, or on material change).