To help address growth in account takeover fraud and authorized push payment scams, market demand, and increasing concern from governments and regulators, card networks have introduced Account Name Inquiry (ANI) functionality. It enables an account cardholder’s name to be checked against the name held by their Issuing bank.

Use Cases

Adding Payment Methods to Digital Wallets - Confirm user information for adding a new payment method to digital wallets for an extra layer of verification to prevent unauthorized pull payments.
Loan funding - check the name of a card before pushing funds to a card on your customers account.
Adding Cards to Push to Card Workflow - Validate users’ names when adding a card to any user account holding funds to prevent unauthorized push payments.
Online Marketplace – Validate user identity pre-transaction, to help ensure secure transactions and reducing fraudulent activities on the platform.
In-game Purchase – Confirm user details before processing in-game purchases to help confirm user names and minimize unauthorized transactions in the gaming environment.

✅
Fighting Fraud as Part of a Layered Control Environment
You can consider using ANI and account verification as part of a multi-layered approach to fraud and scam reduction, and to enhance other know-your-customer (KYC) processes.

Why Choose ANI?

Verify the cardholder’s name helps reduce fraud, especially in push and pull transactions like AFT and OCT.
ANI benefits cardholders, merchants, wallet providers, payout operators, and any payment flow participant wanting a layer or verification.
ANI works independently of the financial transaction, and can work with with Address Verification Service (AVS) or CVV2 as a means to triangulate the customer as an entity that is the true owner, or authorized user of the card.

ANI Workflow

Using ANI, a customer-entered name is checked against the name held by the issuing bank. This check can occur:

During customer onboarding: Verify account names to insure bolster KYC processes.
Just before a transaction: Verify names right before specific high ticket transactions.
Periodically: Ongoing KYC maintenance.
On an ad-hoc basis: Verify names when account information or payment methods are updated.

ANI Example Flow

Visa Key

Match Type	Description
Match	Very close or exact match (e.g., minor spelling mistake)
Partial Match	Potential risk, seek additional checks/retry
No Match	High risk, seek additional checks/retry or block card
No Supported	Issuer does not support ANI

Name Collection: TabaPay Clients collect name from their customer.
Query Card API Request: You send the Query Card API request as part of a customer onboarding or periodic account check process. The generations zero-dollar authorization with the cardholder’s first, middle, and last name, and other credentials for checking such as CVV2 and cardholder billing Address. TabaPay will add the card details and send to Visa.
Card Network Validation: TabaPay reaches out to the Card Networks to perform ANI.
Issuer Confirmation: The network in turn reaches out to the issuing bank to fetch the corresponding cardholder name for the payment card/token. The card network then performs a match and obtains match results.
Query Card API Response: You receive the API response from TabaPay with the name match results. The name match result is broken down into an overall match result.

Visa Match Results

Visa results include individual name match result for each of the first, middle and last names provided. Each match result is either a Match, Partial Match or No Match. You will receive a result of (ANI Performed / Not Performed / Not Supported), and if ANI is performed, a match result will be provided for the names (Match / No Match / Partial Match).

TabaPay Client Decisioning: On receipt of the name match result, the system that triggered the request, along with the account verification, interprets the match result may follow a particular fraud prevention routine defined by the TabaPay Client.

For example, the system may: log a name match success, alert their internal systems to a name match fail, layer the match result with other fraud detection tools and act accordingly, flag the fail to a manual queue or operator, request a (limited count) retry, prevent the transaction from happening, etc. It is up to the TabaPay Client to configure this logic.

ANI Decisioning

The following decisioning matrix is a recommendation, however you may develop your decisioning logic based on the best fit for your business and use case.

Match Result	Example Decisioning
Matched	If a name verification has produced a `Match` result, and no other checks or parameters indicate otherwise, and the TabaPay Client has no other concerns, then the TabaPay Client may decide that this may be a good candidate to proceed with subsequent transactions. Note: ANI is one of the many layers of security that TabaPay Clients have, and it is up to the clients' discretion to use these available tools.
Partial Match	If a Partial Match is obtained, TabaPay Clients should leverage their own risk-based approach / risk criteria before proceeding, or request additional information or retries from their customer before proceeding with subsequent transactions
No Match	The TabaPay Client may choose not to proceed with subsequent transactions

Match Result

Example Decisioning

Matched

If a name verification has produced a Match result, and no other checks or parameters indicate otherwise, and the TabaPay Client has no other concerns, then the TabaPay Client may decide that this may be a good candidate to proceed with subsequent transactions.

Note: ANI is one of the many layers of security that TabaPay Clients have, and it is up to the clients' discretion to use these available tools.

Partial Match

If a Partial Match is obtained, TabaPay Clients should leverage their own risk-based approach / risk criteria before proceeding, or request additional information or retries from their customer before proceeding with subsequent transactions

No Match

The TabaPay Client may choose not to proceed with subsequent transactions

How ANI Works

Get started with ANI by integrating with the TabaPay API.

Query Card API

TabaPay Query Card API returns the match results on Name as received from the card networks.

Key fields to consume for ANI:

codeMatch - for the overall match result
codeFullName - for the match result on the Full Name provided
codeFirstName - for the match result on just the First Name
codeMiddleName - for the match result on just the Middle Name
codeLastName - for the match result on just the Last Name

Request

See how the request includes the query parameters ?ANI. This example also includes AVS.

https: //FQDN/v1/clients/ClientID/cards?ANI+AVS

Response

The ANI response is contained at the bottom of this request.

{
    "SC": 200,
    "EC": "0",
    "card": {
        "pull": {
            "enabled": true,
            "network": "Visa",
            "type": "Credit",
            "regulated": true,
            "currency": "840",
            "country": "840"
        },
        "push": {
            "enabled": true,
            "network": "Visa",
            "type": "Credit",
            "availability": "Immediate",
            "regulated": true,
            "currency": "840",
            "country": "840"
        },
        "bin": "411111",
        "last4": "1111",
        "nameFI": "FORD Instiution"
    },
    "AVS": {
        "avsID": "ShwI3tMDgIkfWJFkFx48lg",
        "networkRC": "85",
        "networkID": "422515122202",
        "authorizeID": "122202",
        "codeAVS": "Y",
        "codeSecurityCode": "M",
        "par": "V0010013022073812195104907179",
        "ANI": {
            "codeMatch": "M",
            "codeFullName": "M",
            "codeFirstName": "M",
            "codeLastName": "M"
        }
    }
}

The example includes the ANI object the contains codeMatch, codeFullName, codeFirstName, and codeLastName.

📘
Using ANI with AVS
Clients are encouraged to grab the avsID from the Query Card API response, and use it in the Create Transaction API request. This would not verify users again during the transaction, but would help track and monitor efficacy of both AVS and ANI on processing.

ANI Results

Please refer ANI Response Codes for the match results you will obtain as a result of the verification.

ANI Compliance

The name used in the ANI service is the name of the cardholder that the card issuer has on file and that is linked to the associated card. This is usually, but not always, the name on card. It is also usually referred to as the legal name.
In an ANI check, the customer provided name is checked against the name that the issuer has on file for the card.
Prior to performing an ANI name verification, the merchant, originator or cardholder should be made aware in card onboarding or registration, that they must provide the name that their issuing bank holds for them. If a cardholder changes their name, marries, uses nick-names or abbreviations, without informing their issuing bank, ANI is likely to return a ‘partial’ or ‘no match’ result. Some, but not all, issuers hold multiple names on a card account PAN, such as both married and maiden name.
Some network ANI requests and match processes are built to support match of a first, middle and last name (e.g. Visa), and other networks may provide a full match or no match (Mastercard). At a minimum, the last name must be provided.
All three names should be used wherever possible. You can only supply one name set at a time (First/Middle/Last name) for matching, per Query Card API request.
If the issuer holds more than one name set against a single card account, or PAN, the issuer will perform checks against each name on file, and return the most viable, or positive match result.

Recipes

6.1 ANI + AVS

Open Recipe