API to Validate Routing Number 122105278

You need to confirm whether ABA routing number 122105278 is valid and identify the bank and location behind it before releasing an ACH payment or onboarding a US payee. By the end of this guide, you’ll be able to validate 122105278 via a single API call, parse the response fields you need for operations and compliance, and integrate the check into your payment flow with caching and safe fallbacks.

What 122105278 Represents and Why to Validate It

Routing number 122105278 is an ABA routing transit number used in the United States to route ACH transfers and other domestic payments. Validating it ensures that:

• The number is structurally correct (checksum and length).
• The record is active and can receive the specified payment type (e.g., ACH).
• You have the bank’s canonical name and address for records, fraud screening, and downstream compliance checks.

Using the BankDataStack Routing Validation API, you can confirm 122105278 and retrieve authoritative bank metadata in a single POST request. See the Documentation for field-level details and additional identifier types supported.

ABA Format and Checksum, in Brief

An ABA routing number is exactly nine digits. The ninth digit is a checksum computed with a 3–7–1 weighted sum:

• Multiply digits 1, 4, 7 by 3; digits 2, 5, 8 by 7; digits 3, 6, 9 by 1.
• Sum the products; a valid routing number gives a total that is a multiple of 10.

While you can implement a local checksum pre-check, always use the API to confirm the bank’s active status, address, and supported payment rails (e.g., ACH). BankDataStack keeps these attributes current and returns a consistent structure for programmatic use.

Validate 122105278 via API

Use the dedicated routing validation endpoint. The example below targets ACH validation of 122105278 and includes an API key header.

curl -X POST "https://www.bankdatastack.com/api/v1/routing/validate" -H "X-API-Key: YOUR_API_KEY" -H "Content-Type: application/json" -d '{"routing_number":"122105278","payment_type":"ach"}'

The service responds with normalized bank data. Here is a real response for this specific routing number and payment type.

{
    "status": "success",
    "data": {
        "routingNumber": "122105278",
        "paymentType": "ach",
        "name": "Wells Fargo Bank Na (arizona)",
        "addressFull": "255 2nd Ave South, Minneapolis, MN 55479",
        "street": "255 2nd Ave South",
        "city": "Minneapolis",
        "state": "MN",
        "zip": "55479",
        "type": "Main Office",
        "phone": "800-745-2426",
        "active": true,
        "lastUpdated": "2026-10-29",
        "address": "255 2ND AVE SOUTH"
    }
}

What to use in your flow:

• data.routingNumber and data.paymentType: Echo what you validated.
• data.name and data.addressFull (plus city/state/zip): Display to users for confirmation and store on the payee profile.
• data.active: Gate payment initiation; if false or missing, block or request correction.
• data.type: Helpful for internal routing rules (Main Office vs. branch types).
• data.lastUpdated: Drive your cache revalidation strategy.
• data.phone: Internal use for ops verification when needed.

Python Example: Validate 122105278 and Gate ACH Payout

This sample calls the same endpoint, checks the response, and prepares a user-facing confirmation string. It assumes this step runs during payee onboarding or before an ACH credit.

import json
import requests

API_KEY = "YOUR_API_KEY"
URL = "https://www.bankdatastack.com/api/v1/routing/validate"

payload = {
"routing_number": "122105278",
"payment_type": "ach"
}

headers = {
"X-API-Key": API_KEY,
"Content-Type": "application/json"
}

resp = requests.post(URL, headers=headers, data=json.dumps(payload), timeout=10)
resp.raise_for_status()
result = resp.json()

if result.get("status") != "success" or "data" not in result:
raise ValueError("Routing validation failed or not found")

data = result["data"]

if not data.get("active", False):
raise ValueError(f"Routing {data.get('routingNumber')} is inactive for {data.get('paymentType')}")

bank_name = data.get("name")
addr = data.get("addressFull") or f"{data.get('street')}, {data.get('city')}, {data.get('state')} {data.get('zip')}"

confirmation = f"Bank: {bank_name} — {addr}"
print(confirmation)

# Example gating rule for ACH:
if data.get("paymentType") == "ach" and data.get("routingNumber") == "122105278":
# Proceed with ACH creation in your system
pass

Integration notes:

• Use the exact fields returned in the JSON to populate your payee record (name, address, active).
• If your UI shows a confirmation step, render bank_name and addr for the payer or payee to verify.
• On “not found” or non-success, prompt the user to re-enter routing/bank details or route to manual review.

Where This Fits in Your Payment and Onboarding Flow

During Payee Onboarding

• Collect account number and routing number (never store the full account number in logs; mask it immediately after use).
• Validate the routing number via the API with payment_type="ach".
• If valid and active, store bank name and address for audit and operational clarity.
• Optionally, perform a micro-deposit or other account confirmation step; the routing validation doesn’t confirm the account number itself.

Before Each ACH Payout

• Re-check cached entries if lastUpdated is older than your policy window (e.g., 30 days), or upon failures.
• Block the payment if active is false or if the lookup no longer resolves.

Handling Errors and “Not Found” Results

If the API response status is not success or data is empty/missing for the routing number, treat it as “not found” for the given payment_type. Practical actions:

• Ask the user to confirm the nine-digit routing number and payment rail (ACH vs. other rails if relevant to your system design).
• Apply local checksum validation as a quick front-end filter to reduce API calls for obviously invalid input.
• Escalate to manual review if the routing number appears historically valid but now fails (e.g., deactivated or merged records).

Caching Strategy and Data Freshness

Routing metadata changes infrequently but can update due to mergers, address normalization, or operational changes. Recommendations:

• Cache positive validations keyed by routing number and payment type.
• Store the response’s lastUpdated and revalidate on a schedule suited to your risk tolerance (for example, days to a month).
• Always bypass cache on user edits and save failures for the same payee to avoid stale data loops.

Identifier Landscape: Where Routing Numbers Fit

Routing numbers are one of several bank/payment identifiers. Here’s a concise comparison to orient your team while keeping this workflow focused on US ACH:

Security and Compliance Notes

• Route validation requests server-side using HTTPS and the X-API-Key header. Never expose your key in front-end code.
• Store only what you need: bank name, normalized address, routing number, payment type, and timestamps. Avoid logging sensitive inputs in plaintext.
• For cards, do not store full primary account numbers; BIN refers only to the leading digits and should be handled per PCI guidance in your environment.

Testing and Environments

For development, you can validate known identifiers to confirm wiring and parsing. The cURL and JSON above demonstrate a successful validation for 122105278. For additional reference formats, the documentation includes other identifier types and samples. When moving to production, ensure timeouts and retries are tuned to your payment orchestration SLAs.

Pricing, Access, and Next Steps

BankDataStack’s Starter plan is $49.99 per month with a 7-day trial. To begin, sign up for an API key and run the exact cURL shown above against your environment.

• Register
• Documentation

FAQ

Does the response confirm the bank account number itself?
No. The routing check confirms bank identity, address, and routing validity for the specified rail (e.g., ACH). To confirm an account number, use additional steps like micro-deposits or your payment processor’s account verification features.

What should I do if the API returns success but active is false?
Block the payment or onboarding step and prompt the user for a different routing number. You can also surface the bank name and address to help them identify the correct details.

How often should I refresh cached routing validations?
Routing metadata is stable but can change. Use lastUpdated in the response to guide revalidation. Many teams recheck cached entries on a schedule from days to a month, or any time a payment fails for that destination.

Can I validate other identifiers alongside routing numbers?
Yes. BankDataStack validates SWIFT/BIC, IBAN (note: the USA does not use IBAN), and card BINs via the same base endpoint pattern. Keep each call focused on the corresponding validate path and input fields as documented.

Which payment_type should I use for US transfers?
Use "ach" for ACH transfers. If you support multiple rails, keep your validation calls aligned with the rail you will actually use for the payment.

Start validating routing number 122105278 and other payees in your workflow now. Create an account to get your API key and ship your integration in minutes: Register.